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(54) Software management system and method 



(57) An operation management system for manag- 
ing the operation of a managed software product. When 
a management target function is executed, reference is 
made to a battery value and, if the value is zero or great- 
er, the function is allowed to be executed. The battery 



value is decremented as the function is executed. A 
charge value is supplied on a charge disk, such as a 
floppy disk, to allow the user to increase the battery val- 
ue and to extend the usage period of the managed soft- 
ware product. The charge value may be supplied over 
a communication line. 
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Description 

BACKGROUND OF THE INVENTION 

Field of the Invention 

This invention relates to an operation management 
system and an operation management method, and 
more particularly to software operation management or 
execution management. 

Description of the Related Art 

As computers and computer use become more 
common, more advanced technology is introduced and 
a variety of software products are developed for use in 
various fields. However, in many cases, the user finds 
it difficult to select a product from among a variety of 
software products that seem to meet the user's require- 
ments; often, the user cannot find the best tool for his 
needs. 

To reduce such a risk, a service has been available 
that supplies the user with a trial-use software product 
free of charge. However, most of these trial-use soft- 
ware products contain only function descriptions or pro- 
vide the user with limited functions (e.g., save function 
and/or output function is/are not included). This makes 
it difficult for the user to evaluate the actual product (all 
the functions) correctly. 

A sales system which charges the user according 
to how long the user actually uses a software product 
(including a trial use) would allow him to buy the product 
anytime he wants, to fully evaluate the product, and to 
precisely determine the requirements for continued use 
(including payment for it). Many users would find this 
type of sales system appealing and economical. 

In Japanese Patent Laid-Open Publication No. Sho 
59-41061 and Japanese Patent Laid-Open Publication 
No. Sho 63-1 53633, a system is disclosed that automat- 
ically prevents a program from being used when the us- 
age count reaches a specified value. In Japanese Pat- 
ent Laid-Open Publication No. Hei 1-147622 a system 
is disclosed which accumulates program execution time 
(total program execution time) and prevents the pro- 
gram from being used when the accumulation time 
reaches a specified amount. However, these systems 
do not disclose means for extending the program usage 
period. Japanese Patent Laid-Open Publication No. Hei 
5-134949 discloses a system in which a program and 
expiry of the program are downloaded from a host com- 
puter to a user computer via a communication line. Also 
disclosed is a system in which a new expiry of the pro- 
gram is downloaded from the host computer to the user 
computer in order to update the expiry. However, the 
system only measures the execution time taken for ex- 
ecuting the entire program, and does not include any 
means for changing the expiry on the user computer. 

In Japanese Patent Laid-Open Publication No. Hei 



7-234785, a system is disclosed that relates to a soft- 
ware rental system. This system connects a computer 
in a rental company to a user computer on which a rental 
software product is running over a communication line. 
5 When the time elapsed from the rental start time reach- 
es the rental limit time, the system makes the program 
unavailable for use. (For example, the program is delet- 
ed.) To allow the user to update the rental period, the 
rental company sends a rental period extension pro- 
f 0 gram to the user's computer over a communication line. 
The user runs this program to extend the rental period 
of the program. A drawback of this system is that the 
user must pay for the software product regardless of 
whether the user has used it frequently or not. This 
is means that the amount of money the user has to pay 
depends, not on how often he has used it, but on how 
long he has used it. 

In Japanese Patent Laid-Open Publication No. Hei 
7-244585, a system is disclosed that manages the pro- 
gram usage period. This system assigns a usage limit 
date to a program and, when the current date becomes 
greater than the limit date, the program product is made 
unavailable. To extend the usage limit date, the system 
reads update limit data from a recording medium con- 
taining that data and re-assigns a usage limit date based 
on the update limit data. This system is not reasonable 
because the amount of money the user has to pay does 
not depend on whether or not the user actually uses the 
program. 

For example, during execution of a Computer Aided 
Design (CAD) software product, the user often spends 
much time thinking without entering data. In the system 
disclosed by the above mentioned Japanese Patent 
Laid-Open Publication No. Hei 7-234785 or Japanese 
Patent Laid-Open Publication No. Hei 7-244585, the us- 
er must pay for this thinking time. This places unwanted 
pressure on the user, especially when he must think 
carefully during program execution. 

SUMMARY OF THE INVENTION 

The present invention seeks to solve the problems 
associated with the art described above. In view of the 
foregoing, it is an object of the present invention to pro- 
vide an operation management system and method 
which reasonably manage the operation of a managed 
software product. 

It is another object of the present invention to pro- 
vide an operation management system and method 
which levy a charge according to the actual usage 
amount of the managed software p roduct (or the amount 
of the result generated by the managed software prod- 
uct). 

It is still another object of the present invention to 
provide an operation management system and method 
which manage the operation according to the property 
of each function of the managed software product. 
(1 ) To achieve the above objects, an operation manage- 
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ment system for managing the operation of a managed 
software product according to the present invention 
comprises: battery value management means for dec- 
rementing a battery value according to the operation 
amount of the managed software product; operation lim- 
it means for limiting the operation of the managed soft- 
ware product when the battery value has decreased to 
a specified limit value; and charge means for adding a 
charge value to the current battery value when the 
charge value is entered from external means. 

The "battery value" mentioned above is a "virtual 
battery" which drives a managed software product. This 
battery value is preferably the value of a counter. 

The battery value management means decrement 
the battery value according to the operation amount of 
the managed software product. When the battery value 
has reached a specified limit value (for example, 0), the 
operation limit means limit all of or a part of the operation 
of the managed software product. Upon receiving a 
charge value (additional battery value) from the external 
means, the charge means add the received value to the 
current battery value, thus extending the operation pe- 
riod. That is, the battery value is incremented, just as a 
battery is charged, to allow the continued use of the 
managed software product. 

The managed software product described above is 
preferably a packaged application software program in- 
cluding a CAD program, game program, video program, 
language processor, music program, communication 
program, or a measurement program. 

The battery value management means, operation 
management means, and charge means described 
above should be implemented preferably as software 
programs (management software programs) that run on 
a computer The managed software product and the 
management software product may be separate, or the 
whole or a part of the management software product 
may be included in the managed software product. 

A system according to the present invention is im- 
plemented on a general-purpose computer or special- 
purpose computer having such peripheral units as adisk 
drive, display, and input unit. The external means de- 
scribed above include recording media such as a mag- 
netic disk or an optical disk and other host computers 
connected over a network. 

(2) An operation management system according to the 
present invention may be applied to an application soft- 
ware product sales system. The following explains an 
example: 

A vendor sells an application software product con- 
taining the operation management program according 
to the present invention. The operation management 
program has a battery value defined as the initial value. 
In addition to this product, the vendor sells recording 
media containing charge values (e.g., floppy disk (FD)). 
In this case, it is desirable that a variety of recording 
media, each containing a unique charge value, be sup- 
plied. 



On the other hand, a user who bought the applica- 
tion software product may use the product until the bat- 
tery value reaches zero. This allows the user to fully 
evaluate and examine the product A user who wants to 
s use the product after the battery value becomes zero 
must buy a recording medium containing a charge value 
to charge the battery. This enables him to add a charge 
value to the battery value and to use the product con- 
tinuously. 

10 |f the specifications of the application software prod- 
uct do not satisfy the user's request, the user does not 
buy the recording medium. This prevents additional 
charges and reduces the cost to the user. 

Considering an increase in the sales profit in record- 

15 jng media that will be produced in the future, a combi- 
nation of a managed software product and the operation 
management program will lower prices significantly. The 
operation management system according to the present 
invention will increase the profits of both the user and 

20 the vendor, making it possible to build a very reasona- 
ble, economical system. 

(3) In a preferred embodiment of the present invention, 
the battery value management means calculate the op- 
eration amount of each function of the managed soft- 

25 ware product, and subtracts a value corresponding to 
the operation amount from the battery value. 

A continuous decrease in the battery value during 
execution of a managed software product, as in a con- 
ventional system, decrements the value even when the 

30 user is idle (input wait time), which places pressure on 
the user. 

Calculating the operation amount of each function 
during execution of a managed software product, as in 
a system according to the present invention, decreases 
35 the battery value only when the managed software prod- 
uct is actually used, enabling the user to do operation 
without having to worry about time elapsed while think- 
ing. 

(4) In a preferred embodiment of the present invention, 
40 function category determination means are also availa- 
ble which determine if an execution instruction from the 
user activates a management target function or a man- 
agement non-target function. And, the battery value 
management means decrement the battery value only 

45 when the management target function is executed. 

For example, with the data generation function de- 
fined as a management target function and with other 
functions as management non-target functions, a cost 
can be levied only when new data are generated. 

50 (5) In a preferred embodiment of the present invention, 
the battery value management means have a weight ta- 
ble containing an operation amount weight value for 
each of the management target functions. When any of 
the management target functions is executed, the bat- 

55 tery value management means decrement the battery 
value by the weight value corresponding to the manage- 
ment target function. 

In a preferred embodiment of the present invention, 
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the battery value management means measure the ex- 
ecution time of each of the management target functions 
and decrement the battery value by the value corre- 
sponding to the execution time. 

This weight value system is able to calculate the op- 
eration amount regardless of the computer speed, 
which may differ among computers. In addition, by 
measuring time in this manner, the execution time is di- 
rectly monitored and therefore the operation mount be- 
comes proportional to the CPU load. 

(6) In a preferred embodiment of the present invention, 
the operation limit means prevent only the management 
target functions from being executed when the battery 
value has decreased to a specified limit value; manage- 
ment non-target functions are executed. 

For example, forcing a game program used at home 
to terminate when the battery value has reached a spec- 
ified value does not cause a serious problem. 

However, for a CAD program used in an office, 
forced termination when the battery value has reached 
a specified value may make already-produced data un- 
available, possibly interrupting a job. Therefore, consid- 
ering user's advantage and convenience, the embodi- 
ment keeps some functions operable even when the 
battery value has reached a specified value. 

(7) A preferred embodiment of the present invention has 
remainder warning means for issuing a remainder warn- 
ing message when the battery value has decremented 
to a specified warning value because a sudden inoper- 
able condition in the managed software product without 
prior notice may cause the user unexpected damage. 
The remainder warning means alert the user to that con- 
dition before it occurs. In other words, the warning mes- 
sage prompts the user to determine whether to charge 
the battery value. 

A preferred embodiment of the present invention 
has remainder display means for displaying the battery 
value on the screen during execution of the managed 
software product. This remainder display information 
keeps the user informed of the amount by which the 
managed software product will be able to continue op- 
eration without being charged. 

It is also possible to program the system so that, 
upon detecting that the battery value has been charged 
to a specified value, the system can automatically disa- 
ble operation management through the battery value to 
allow the user to use the product indefinitely. 

(8) To achieve the above objects, a method for manag- 
ing the operation of a managed software product ac- 
cording to the present invention comprises: a count val- 
ue management step for changing a count value accord- 
ing to the operation amount of the managed software 
product; an operation limit step for limiting the operation 
of the managed software product when the count value 
has reached a specified limit value; and a charge step 
for charging the current count value or the limit value 
when a charge value is entered from external means. 

The above count value is incremented or decre- 



mented according to the operation amount of the man- 
aged software product. When the count value is incre- 
mented, a charge value is added to the limit value; when 
the count value is decremented, a charge value is added 
5 to the current count value. In either case, the usage pe- 
riod is extended by charging the battery value. 

BRIEF DESCRIPTION OF THE DRAWINGS 

'0 Fig. 1 is a diagram showing a user machine used in 
the operation management system according to the 
present invention. 

Fig. 2 is a diagram showing the data structure of a 
charge disk. 

'5 Fig. 3 is a diagram showing the concept of the op- 
eration management system according to the present 
invention. 

Fig. 4 is a diagram showing an example of the his- 
tory table. 

20 Fig. 5 is a diagram showing an example of the us- 
age amount table. 

Fig. 6 is a flowchart showing the processing of the 
system when a management target function is executed 
in the execution time based method. 

25 Fig. 7 is a flowchart showing the processing of the 
system when a management target function is executed 
in the weight value based method. 

Fig. 8 is a flowchart showing the charge disk read 
processing. 

30 Fig. 9 is a flowchart showing the charge processing. 
Fig. 10 is a diagram showing a user machine used 
in another embodiment. 

Fig. 11 is a diagram showing the structure of data 
sent from the host machine to a user machine. 
35 Fig. 1 2 is a diagram showing the concept of the sys- 
tem in another embodiment. 

Fig. 1 3 is a diagram showing an example of the user 
registration table. 

Fig. 14 is a flowchart showing the operation of the 
40 user machine and a user machine in another embodi- 
ment. 

Fig. 15 is a diagram showing another configuration 
of the system. 

Fig. 16 is a diagram showing an example of an ap- 
45 plication according to the present invention. 

Fig. 1 7 is a flowchart showing the function category 
determination processing. 

DESCRIPTION OF PREFERRED EMBODIMENTS 

50 

Fig. 1 shows a user machine 1 0. This user machine 
10 is a computer which executes various types of appli- 
cation programs under control of the operation system 
(OS). The user machine 10 is composed of a system 
55 unit 12, display 14, keyboard (not shown in the figure), 
output unit (not shown in the figure) such as a printer or 
plotter, and so forth. The system unit 1 2 contains a CD- 
ROM disk drive 16 which accesses a CD-ROM and 
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reads data from it and a floppy disk drive 20 which ac- 
cesses a floppy disk (FD) and reads data from it. 

The CD-ROM shown in Fig. 1 contains a managed 
software product 18. In this embodiment, the managed 
software product 18, such as a CAD software product, 
has an operation management program built in. The op- 
eration management program, designed for managing 
the operation of the managed software product 1 8, man- 
ages the operation using a "battery value" which will be 
described below. In the example shown in Fig. 1, the 
managed software product 18 is installed from the CD- 
ROM to the user machine 10; it may be installed from 
any other recording medium or via a communication 
line. 

A charge disk 22, containing specified data (includ- 
ing a charge value) on a floppy disk, functions as a bat- 
tery value charger. Inserting this charge disk 22 into the 
floppy disk drive 20 causes a charge value to be read 
and enables the user to extend the allowable operation 
period of the managed software product 18. In this em- 
bodiment, several charge disks 22, each containing a 
unique charge value, are supplied to allow the user to 
select or buy a desired charge disk 22 to add a desired 
charge value to the battery value. 

The managed software product 18 and the charge 
disk 22 are usually supplied from the same vendor. In 
this embodiment, the managed software product 18 in- 
cludes the operation management program. Of course, 
the managed software product 18 and the operation 
management program may be separately loaded into 
the user machine 10. 

In Fig. 1 , the display 14 has a remainder information 
area 24 where remainder information is displayed and 
a remainder warning area 26 where a warning message 
is displayed when the remainder drops below the spec- 
ified amount. These areas will be described later. 

Fig. 2 shows the data structure of the charge disk 
22. As shown in Fig. 2, the charge disk 22 contains a 
serial number 28, management information 30, and 
charge value (additional battery value) 32. The serial 
number 28 is a unique identification number that is as- 
signed when the floppy disk is formatted. Usually, this 
number is not copied when the disk is copied. The man- 
agement information 30 is created when the serial 
number 28 is encrypted. This management information 
30 is copied when the disk is copied. Therefore, when 
the disk is copied illegally, the serial number 28 and the 
management information 30 do not match, thereby mak- 
ing it easy to determine that the disk is copied illegally. 
Of course, any other conventional security system may 
also be used instead of this method. 

The charge value 32 is an additional charge value 
to be added to the battery value that is decremented as 
the user uses the managed software product 1 8. Charg- 
ing the battery value with this charge value enables the 
user to extend the usage period. 

When the battery value is managed in the "execu- 
tion time based method" in which the battery value is 



decremented by the execution time of each function, an 
additional time is recorded as the charge value 32. On 
the other hand, when the battery value is managed in 
the "weight value based method" in which the battery 
s value is decremented by the weight value of each func- 
tion, the additional value is recorded as the charge value 
32. These methods will be described in more detail later. 

Although a floppy disk is used as the charge disk 
22 in the embodiment shown in Fig. 1 , other types of 
w recording media may also be used. Also, as shown in 
another embodiment that will be explained later, a 
charge value may be sent over a communication line. 

Fig. 3 shows the concept of the operation manage- 
ment system which uses the charge disk 22. The system 
15 is composed primarily of the user machine 10, charge 
disk 22, and vendor's machine 34. In this embodiment, 
the managed software product 18 including the opera- 
tion management program 36 is installed in the user ma- 
chine 10. 

The charge disk 22 is generated on the vendor's 
machine 34 owned by the vendor which sold the man- 
aged software product 18. More specifically, the ven- 
dor's machine 34 has two software modules: the man- 
agement information creation module 52 and the charge 
value issuance module 54. The management informa- 
tion creation module 52 encrypts the serial number 28 
recorded on the charge disk 22, and writes the resulting 
management information 30 back onto the charge disk 
22. Note that the operation management program 36, 
which contains the encryption condition or the decryp- 
tion condition, can check whether or not the serial 
number 28 agrees with the management information 30. 
The charge value issuance module 54 records the 
charge value 32, which has been set by the vendor, onto 
the charge disk 22. In the execution time based method, 
the charge value 32 is recorded, for example, as 100 
hours, 200 hours, or 500 hours. Note that the operation 
management program 36 contains an initial battery val- 
ue (for example, 100 hours). 

The operation management program 36 has a 
counter 38 which decrements the battery value (battery 
value management function). In this embodiment, the 
operation management program 36 decrements the 
counter 38 each time a "management target function' 
provided by the managed software product 18 is exe- 
cuted. When the battery value, i.e., the counter value, 
has decremented to the limit value of 0, the operation 
management program 36 prevents management target 
functions from being executed. That is, in this embodi- 
ment, when the battery value has reached a specified 
limit value, the execution of the managed software prod- 
uct 18 is limited and, when the battery value is charged 
with the charge value 32 contained on the charge disk 
22, the charge value is added to the battery value and 
the resulting value is used as a new battery value. The 
usage period of the managed software product 18 is 
thus extended. 

A history table 40 managed by the operation man- 
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agement program 36 contains history information on 
charge values recorded on the charge disk 22. Fig. 4 
shows an example. As shown in Fig. 4, the history table 
40 is composed of three columns: FD serial number col- 
umn 40A, charge data/time column 40B, and charge val- 
ue column 40C. The table may have other columns as 
necessary. 

Referring to Fig. 3 again, the following explains how 
the battery value is managed. When the battery value 
is managed in the "execution time based method' de- 
scribed above, the execution time of each management 
target function, measured based on the internal clock 
42, is subtracted from the battery value. On the other 
hand, when the "weight value based method" described 
above is used, the battery value is managed based on 
the usage amount table 44. Fig. 5 shows an example of 
the usage amount table 44. In this embodiment, the ta- 
ble contains entries, each consisting of a function name 
44A and the corresponding usage amount 44B. It should 
be noted that each usage amount is used as a weight 
value. For example, a weight value is pre-defined ac- 
cording to the processing time of each function. There- 
fore, when a management target function is executed, 
the corresponding usage amount (weight value) is sub- 
tracted from the battery value. 

The managed software product 18 shown in Fig. 3 
has many user interface programs as well as many in- 
ternal functions and common functions used by the pro- 
grams. These functions are classified roughly into two: 
management target functions and management non- 
target functions. Whenever the managed software prod- 
uct 18 attempts to execute a management target func- 
tion, the operation management program 36 references 
the battery value and, when it is zero or greater, allows 
the managed software product 18 to execute that func- 
tion. When the managed software product 18 attempts 
to execute a management non-target function, the op- 
eration management program 36 does not check the 
battery value. For example, when input/output function 
for processing generated data 50 from the managed 
software product 18 is defined as a management non- 
target function, the input/output processing is always ex- 
ecuted on the generated data 50, even if the usage pe- 
riod of the managed software product 18 has expired. 
This ensures that the generated data 50 are always 
processed, thus protecting user assets. Examples of 
management non-target functions include the data dis- 
play function, data print function, and data plotter output 
function. 

Management target functions include the data gen- 
eration function. For example, when the managed soft- 
ware product is a CAD software product, the data gen- 
eration function includes the straight-line drawing func- 
tion, curved-line drawing function, circle drawing func- 
tion, area fill-in function, area hatching function, and 
character insertion function. 

Fig. 3 conceptually shows management target func- 
tion execution module 46 which executes management 



target functions and management non-target function 
execution module 48 which executes management non- 
target functions. In this embodiment, the battery value 
is decremented only when a management target func- 

5 tion is activated. Note that the battery may be decre- 
mented when both a management target function and a 
management non -target function are activated. 

In addition to the data described above, the charge 
disk 22 may contain other types of data. For example, 

io it may contain the name of the managed software prod- 
uct 1 8 which accepts a charge value. In this case, the 
name of the managed software product 18 is used as 
follows. When the charge disk 22 is read, the operation 
management program 36 checks whether or not the 

15 name of the managed software recorded on the charge 
disk 22 matches that of the managed software product 
18 installed in the user machine 10 and, only when they 
match, accepts the charge value 32. 

The battery value described above is stored on the 

20 hard disk and then copied into the computer's RAM. The 
battery value in the RAM is decremented whenever a 
management target function is executed. Also, at an in- 
terval or as necessary, the battery value in the RAM re- 
places the battery value on the hard disk. This means 

25 that, even when the computer fails, the battery value is 
not erased. The battery value may also be maintained 
in some other way. 

Fig. 17 is a flowchart showing how the operation 
management program operates when it accepts an in- 

30 struction requesting the execution of a managed soft- 
ware product function. The following explains this 
processing in more detail. 

Upon receiving from a user an instruction request- 
ing the execution of a function of the managed software 

35 product while the managed software product is in exe- 
cution (S601), the operation management program 
checks whether the requested function is a manage- 
ment target function or a management non-target func- 
tion (S602). When the function is a management target 

40 function (S603), the operation management program 
performs the processing shown in Fig. 6 or Fig. 7 (S604). 
When the function is a management non-target function 
(S603), the program executes the function immediately. 
(S605). This processing is repeated whenever an exe- 

<5 cution instruction is received. 

Next, referring to Fig. 3, the execution of a manage- 
ment target function in the execution time based method 
is explained with the use of Fig. 6. 

When the user requests the execution of a manage- 
so ment target function while the managed software prod- 
uct 18 shown in Fig. 3 is in execution, the routine shown 
in Fig. 6 is started. First, the management targetfunction 
execution module 46 or the operation management pro- 
gram 36 reads the battery value to check if it is greater 

55 than zero. If the battery value is zero or less, the routine 
is terminated. That is, the requested management target 
function cannot be started. Note that a management 
non-target function is started even if the battery value is 
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zero. 

In S102, the routine gets the start time from the in- 
ternal clock 42 before starting the requested manage- 
ment target function and, in S103, starts the manage- 
ment target function. In S104, the routine gets the end 
time from the internal clock 42 and, in S105, subtracts 
the start time from the end time to calculate the process- 
ing time (execution time) of the processing executed in 
S103. 

In S106, the routine subtracts the processing time 
calculated in S105 from the battery value. In S107, the 
routine checks if the resulting battery value is equal to 
or less than the warning value and, if so, displays a mes- 
sage in the remainder warning area 26 shown in Fig. 1 . 
If the resulting battery value is greater than the warning 
value, the routine does not display the message. As 
shown in Fig. 1 , the remainder information area 24 is 
displayed during execution of the managed software 
product 18 (see Fig. 1) to allow the user to check the 
remaining amount. This helps the user determine how 
long he can execute the managed software product 1 8. 

Fig. 7 shows the processing of a management tar- 
get function in the weight value based method. 

When the execution of a management target func- 
tion is requested as described above, the routine refer- 
ences the battery value in S201 to check if it is equal to 
or greater than 0. If it is, the routine executes the re- 
quested management target function in S202 and, in 
S203, references the usage amount table 44 shown in 
Fig. 5 to find the usage amount (weight value) of the 
executed management target function. Then, in S204, 
the routine subtracts the processing amount found in 
S203 from the battery value to find a new battery value. 
In S205, the routine checks if the battery value is less 
than the warning value and, if so, displays a message 
in the remainder warning area 26 in S206. 

The "execution time based method' shown in Fig. 
6 allows the user to manage operation using a physical 
amount that is easy to understand. In addition, the user 
can manage operation in a relatively simple configura- 
tion. On the other hand, the "weight value based meth- 
od" shown in Fig. 7 gives the user the same result re- 
gardless of the CPU speed of the user's machine. 

Next, referring to Fig. 3, the charge disk 22 read 
processing is explained with the use of Fig. 8. 

This processing is started when the charge disk 22 
is inserted into the floppy disk drive 20 as shown in Fig. 
1 . The routine reads the serial number in S301 , and the 
management information in S302, both from the charge 
disk 22. In S303, the routine encrypts the serial number 
according to the encryption condition, or decrypts the 
management information according to the decryption 
condition, and compares the serial number with the 
management information. This comparison determines 
whether or not the charge disk 22 is legal. For example, 
when the disk is illegally copied, the management infor- 
mation 30 is copied, but the serial number 28 is not cop- 
ied but replaced. This results in a mismatch between the 



serial number 28 and the management information 30, 
thereby making it possible to find an illegal copy 

In S304, the routine checks if the charge disk 22 is 
valid and, if it is not valid, terminates processing in S308. 
5 If it is valid, the routine references the history table 40, 
containing past charge history data, in S305 to check 
the validity of the charge value 32 recorded on the 
charge disk 22. To do so, the routine first checks to see 
if the serial number 28 of the charge disk 22 is in the 

10 history table 40. If the serial number is found, the routine 
takes the following steps to check if the charge value 32 
recorded on the charge disk 22 is valid. The routine finds 
the charge value initially recorded on the charge disk 22 
and, from that initial value, subtracts the actual charge 

*5 value to find the remainder. The next time the battery 
value is charged, the routine compares the remainder 
with the charge value currently recorded on the charge 
disk. If the charge value on the charge disk 22 is greater 
than the remainder, the routine determines in S306 that 

^0 the charge disk is not valid and terminates processing 
in S308. If the routine finds that the charge value 32 on 
the charge disk 22 is valid, it performs the charge 
processing, shown in Fig. 9, in S307. 

Fig. 9 shows an example of charge processing. In 

25 S401 , the routine references the counter 38 to read the 
current battery value and, in S402, reads the charge val- 
ue from the charge disk 22. In S403, the routine asks 
the user to type an actual charge value that does not 
exceed the charge value 32 recorded on the charge disk 

30 22. The user types the charge value, for example, from 
the keyboard. In S404, the routine checks that the spec- 
ified charge value is less than the charge value on the 
charge disk 22. If the specified charge value is greater 
than the charge value on the charge disk 22, the routine 

55 asks the user to retype the charge value. 

In S405, the routine adds the specified charge value 
to the battery value, thus charging the battery value. In 
S406, the routine subtracts the specified charge value 
from the initial charge value and writes the resulting val- 

^0 ue on the charge disk 22 as a new charge value 32 . If 
the initial charge value 32 is exhausted, the routine 
writes the value of 0 on the charge disk 22 to virtually 
erase the charge value. The value of 0 prevents the 
charge disk 22 from being re-used. In S407, a record 

« relating to the charge processing is added to the history 
table 40. 

In the above embodiment, the user specifies an ac- 
tual charge value. Instead of having the user specify a 
value, a pre-defined charge value may be added to the 
50 battery value at that time. 

Fig. 1 0 shows another embodiment according to the 
present invention. In the embodiment described above, 
the battery value is charged using a recording medium. 
In this embodiment, the battery value is charged via a 
55 communication line 60. For the same components as 
those used in the above embodiment, the same num- 
bers are assigned and their descriptions are omitted. 
The user machine 10 in Fig. 10 is connected to the 
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host machine 62 via the communication line 60. From 
this host machine 62, send data 64 shown in Fig. 11 are 
sent to the user machine 1 0 to charge the battery value. 

In Fig. 11 , address information 68 specifies the ad- 
dress of the user machine 10. Management information 
70 is created by encrypting the serial number on the re- 
cording medium containing the managed software prod- 
uct 18. A charge value 72, a value to be added to the 
battery value as with the above embodiment, is an ad- 
ditional period of time in the execution time based meth- 
od, and is an additional amount in the weight value 
based method. 

Fig. 12 illustrates the system concept of this embod- 
iment. 

As described above, the user machine 10 is con- 
nected to the host machine 62 via the communication 
line 60. That is, this host machine 62 is connected to 
each of a number of user machines 1 0 for integrated 
operation management. This host machine 62 has a 
management information creation module 76, charge 
value issuance module 78, user registration table 80, 
and billing module 82. The management information 
creation module 76 creates the management informa- 
tion 70 shown in Fig. 11 , and the charge value issuance 
module 78 issues a charge value 72 in response to a 
request from the user machine 1 0. As shown in Fig. 1 3, 
the user registration table 80 is composed primarily of 
the user ID column 80A, user name column 80B, and 
request charge value column 80C. The billing module 
82 references the user registration table 80 to automat- 
ically issue a bill for a requested amount whenever a 
charge value is issued, or at some specified interval. 

Next, referring to Fig. 12, the operation of this em- 
bodiment is explained with the use of Fig. 14. The op- 
eration of the user machine 10 is shown in the left side 
of Fig. 14, while that of the host machine 62 is shown 
on the right. 

First, in S501 and S502, the user machine 10 is con- 
nected to the host machine 62 via a communication line. 
In S503, the user machine 10 generates a request for a 
charge value that will be sent to the host machine 62. In 
this case, the request contains at least the serial number 
of the CD-ROM containing the managed software prod- 
uct 18 and information on the charge value. In S504, the 
user machine sends the request to the host machine 
and, in S505, the host machine receives the request. 

In S506, the host machine checks the user registra- 
tion table 80. If the host machine finds, in S507, that the 
requesting user is registered in the host machine 62, the 
management information creation module 76 creates 
management information based on the serial number in 
S508, and the charge value issuance module 78 gener- 
ates a charge value in response to the request from the 
user. In S509, the host machine 62 sends the manage- 
ment information and the charge value to the user ma- 
chine 1 0 as the send data 64 shown in Fig. 1 1 . In S51 0, 
the user machine 10 receives the send data 64. In S511 
and S512, the user machine 10 and the host machine 



62 are disconnected. 

In S513, the operation management program 36 
compares the serial number 74 with the management 
information 70 to check to see if the data received by 
s the user machine 10 are valid. This prevents the user 
from illegally charging the battery value. If it is found in 
S51 4 that the send data are valid, the charge processing 
is performed in S515. This charge processing is the 
same as that in Fig. 9. 
10 As shown in Fig. 1 2, this embodiment may also use 
the execution time based method or the weight value 
based method in order to manage the battery value. 

Although the battery value is charged over a com- 
munication line such as a telephone line in the above 
is embodiment, it may also be charged over a communi- 
cation satellite (satellite line). 

In the above embodiments, the operation manage- 
ment program 36 is included in the managed software 
product 1 8. Of course, an external program can manage 
the operation of the managed software product 18. Fig. 
15 shows the concept of such an embodiment. 

As shown in Fig. 15, the operation system (OS) 83 
is located between the hardware 81 and each of appli- 
cation programs 84, 86, and 88. The operation manage- 
ment program 36 according to the present invention 
may be located between the operation system 83 and 
the application program 84. 

Operation management program 36 therefore func- 
tions as an interface program. Messages are ex- 
changed between the operation management program 
36 and the application program 84 according to some 
specific rule. Messages are also exchanged between 
the operation management program 36 and the opera- 
tion system 83 according to a specific rule. 

To execute a management target function in this 
configuration, the operation management program 36 
references the battery value when it receives an execu- 
tion request from the application program 84. If the bat- 
tery value is not zero, the operation management pro- 
gram 36 sends an instruction to the operation system 
83 while simultaneously decrementing the battery value 
by a value corresponding to the function. If the battery 
value is zero, the operation management program 36 
sends a message back to the application program 84, 
indicating that the instruction cannot be executed. 

To execute a management non-target function, the 
operation management program 36 does not reference 
the battery value when it receives an execution request 
from the application program 84 but instead sends the 
instruction directly to the operation system 83. 

The battery value is decremented as management 
target functions are executed. Charging the battery val- 
ue allows the user to extend the usage period of the ap- 
plication program 84, which may be supplied separately 
from the application program 84. 

In the above embodiments, one operation manage- 
ment program manages one operation management 
program. It is also possible for one operation manage- 
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ment program to manage several application programs. 

Fig. 16 shows an application of the present inven- 
tion. The system shown in Fig. 16 is composed of one 
host machine 90 and several user machines 92. Within 
each user machine 92 are a managed software product 
18 and the operation management program 36, which, 
in turn, contains the counter 38 where the battery value 
to be decremented is stored. In other words, the opera- 
tion of the managed software product 18 is controlled 
by the value stored in the counter 38. To execute the 
managed software product 18 in this system, it is nec- 
essary to insert a battery disk 96 into the user machine 
92 and to move the battery value from the battery disk 
96 into the counter 38. The battery value is decremented 
as the operation of the managed software product 16 
proceeds. When the user finishes the managed soft- 
ware product 1 8, a sequence of operations are executed 
to move the current counter value from the counter 38 
to the battery disk 96. This initializes the counter 38 to 
zero just as it was before the battery disk 96 was insert- 
ed. 

The host machine 90 has several disk drives into 
which a battery disk 96 is inserted to read the battery 
value that was returned to the battery disk 96. This host 
machine 90 is also used to charge the battery value on 
the battery disk 96. 

Integrated management of the battery values on 
several battery disks 96 through the host machine 90 
brings a benefit of integrally managing several managed 
software products 18. 

This type of system may be used, for example, in a 
school or a business where many computers are in- 
stalled. With an individual carrying his or her own port- 
able battery disk 96, it is possible to check and control 
the software usage amount of each person. In this case, 
either the "execution time based method" or the "weight 
value based method" may be used. 



Claims 

1. An operation management system for managing 
the operation of a managed software product, com- 
prising: 

battery value management means for decre- 
menting a battery value according to the oper- 
ation amount of said managed software prod- 
uct; 

operation limit means for limiting the operation 
of said managed software product when said 
battery value has decremented to a specified 
limit value; and 

charge means for adding a charge value to the 
current battery value when the charge value is 
entered from external means. 

2. An operation management system according to 



claim 1 , wherein said battery value management 
means find the operation amount for each execu- 
tion of a function owned by said managed software 
product and subtract a value corresponding to said 
5 operation amount from said battery value. 

3. An operation management system according to 
claim 2, further comprising: 

function category determination means for 
io determining if a function to which an execution in- 
struction is issued is a management target function 
or a management non-target function, wherein said 
battery value management means decrement said 
battery value only when said management target 
f£ function is executed. 

4. An operation management system according to 
claim 3, wherein 

20 said battery value management means has a 

weight table containing pairs of said manage- 
ment target function and a weight value repre- 
senting said operation amount thereof, and 
said battery value management means sub- 
25 tract a weight value corresponding to said man- 

agement target function from said battery value 
when said management target function is exe- 
cuted. 

30 5. An operation management system according to 
claim 3, wherein, when said management target 
function is executed, said battery value manage- 
ment means measure the execution time and sub- 
tracts the execution time from said battery value. 

35 

6. An operation management system according to 
claim 3, wherein said operation limit means prevent 
said management target function from being exe- 
cuted but allows said management non-target f unc- 

40 tion to be executed when said battery value has 
reached a limit value. 

7. An operation management system according to 
claim 3, wherein said managed software product 

45 has a data generation function and a data output 
function and wherein said function category deter- 
mination means determine said data generation 
function as said management target function and 
determine said data output function as said man- 
50 agement non-target function. 

8. An operation management system according to 
claim 1, further comprising remainder warning 
means for issuing a remainder warning when said 

55 battery value has decremented to a warning value. 

9. An operation management system according to 
claim 1, further comprising remainder display 
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means for displaying said battery value during ex- 
ecution of said managed software product. 

10. An operation management system for managing 
the operation of a managed software product, com- 
prising: 

battery value management means for decre- 
menting a battery value according to the oper- 
ation amount of said managed software prod- 
uct; 

operation limit means for limiting the operation 
of said managed software product when said 
battery value has decremented to a specified 
limit value; 

read means for reading a charge value from a 
recording medium containing the charge value 
thereon; and 

charge means for adding said charge value to 
the current battery value. 

11. An operation management system according to 
claim 10, further comprising erase means for eras- 
ing the charge value from said recording medium 
after said charge value is added. 

12. An operation management system according to 
claim 10, further comprising: 

specification means for allowing a user to spec- 
ify an actual charge value by which the current 
battery value is to be actually charged, the ac- 
tual charge value not exceeding the charge val- 
ue recorded on said recording medium; and 
rewrite means for rewriting the charge value on 
said recording medium with a remainder value 
after said actual charge value is added to the 
current battery value. 

13. An operation management system according to 
claim 10, in which said recording medium contains 
not only said charge value, but also the identifica- 
tion number of the recording medium and manage- 
ment information generated through encryption of 
the identification number, said operation manage- 
ment system further comprising: 

validity determination means for comparing 
said identification number with said management 
information considering the condition of said en- 
cryption to determine the validity of said recording 
medium. 

14. An operation management system comprising: 

a managed machine containing a managed 
software product; and 

a managing machine connected to said man- 
aged machine with a communication line, 



wherein 

said managed machine comprises: 
battery value management means for decre- 
menting a battery value according to the oper- 
5 ation amount of said managed software prod- 

uct; 

operation limit means for limiting the operation 
of said managed software product when said 
battery value has decremented to a specified 

10 limit value; 

charge value receive means for receiving a 
charge value from said managing machine; and 
charge means for adding said charge value to 
the current battery value, and wherein 

15 said managing machine comprises: 

charge value send means for sending said 
charge value to said managed machine. 

15. An operation management system according to 
20 claim 14, wherein said managed machine further 

comprises: 

notification means for notifying said managing 
machine of the identification number of a port- 

25 able recording medium initially containing said 

managed software product; and 
validity determination means for comparing 
management information sent from said man- 
aging machine with said identification number 

30 to determine the validity of the recording medi- 

um; and wherein said managing machine fur- 
ther comprises: 

management information creation means for 
creating said management information gener- 
35 ated by encrypting said notified identification 

number and for sending the management infor- 
mation to said managed machine. 

16. An operation management system comprising: 

40 

at least one managed machine containing a 
managed software product; and 
a managing machine for managing the opera- 
tion of said managed machine, wherein said 
4 $ managed machine comprises: 

a counter containing a battery value changing 
according to the operation amount of said man- 
aged software product; 

first charge means for reading a battery value 
50 from a portable recording medium to store the 

battery value into said counter; and 
first return means for writing the current battery 
value on said recording medium, and wherein, 
said managing machine comprises: 
55 second charge means for writing said battery 

value on said recording medium; and 
second return means for reading said battery 
value from said recording medium. 
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17. An operation management method comprising: 

a count value management step for changing 
a count value according to the operation 
amount of a managed software product; s 
an operation limit step for limiting the operation 
of said managed software product when said 
count value has reached a specified limit value; 
and 

a charge step for charging the current count val- i o 
ue or said limit value when a charge value is 
entered from external means. 

1 8. A medium containing a management software prod- 
uct for managing the operation of a managed soft- '5 
ware product, wherein said managed software 
product and said management software product are 
executed on computers, said management soft- 
ware product comprising: 

20 

a module for changing a count value according 
to the operation amount of said managed soft- 
ware product; 

a module for limiting the operation of said man- 
aged software product when said count value 25 
has reached a specified limit value; and 
a module for charging the current count value 
or said limit value when a charge value is en- 
tered from external means. 

30 

1 9. A medium containing a charge value read by a man- 
agement software product for use in managing the 
operation of a managed software product, wherein 
said managed software product and said manage- 
ment software product are executed on computers, 3$ 
said management software product comprising: 

a module for changing a count value according 
to the operation amount of said managed soft- 
ware product; 40 
a modulefor limiting the operation of said man- 
aged software product when said count value 
has reached a specified limit value; and 
a module for charging the current count value 
or said limit value when said charge value is 4$ 
entered. 

20. A computer system having an interface software 
product between an operation system and at least 
one application software product, wherein said in- so 
terface software product comprises: 

a module for changing a count value according 
to the operation amount of said application soft- 
ware product; ss 
a module for limiting the operation of said ap- 
plication software product when said count val- 
ue has reached a specified limit value; and 



a module for charging the current count value 
or said limit value when a charge value is en- 
tered from external means. 
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